This is the second part of the blinkd fix (issue #54).

PR #64 prevented the deadlock during service start.

However, currently blinkd is not starting at system boot, because
it uses `env python3` in the shebang. This will activate our default
(big, scientific) python3 which is located in /pkg and depends
on the automounter.

One solution to this problem would be to add After=automount.service
to blinkd.service. This would delay the startup of blinkd to the
point, when automounter has finished startup. However, experiments
showed, that this doesn't work. It looks like the startup
command of automount.service exists after daemon process has been
forked but before the automount paths have been mounted. So
systemd regards automount.service has started before the automount
paths are really available and services with After=automount.service
are still started to early to use them.

That aside, although /usr/bin/python3 depends on /pkg, it is not
supposed to go via NFS under normal circumstances, because of the
local mechanism on mxpkg. However, under exceptional circumstances
(e.g. transition to a new python3 version) it might go over
NFS and we don't want long-running deamons to lock nfs mounts.

A python3 with the blink1 package from PyPi has been added
to the system [1] and is available as
/usr/local/system/python3/bin/python3.

This python installation is guaranteed to be on a local
disk, so use this path in the shebang.

[1] mariux64/pkg-scripts@8e149c1

This is the second part of the blinkd fix (issue #54).

PR #64 prevented the deadlock during service start.

However, currently blinkd is not starting at system boot, because
it uses `env python3` in the shebang. This will activate our default
(big, scientific) python3 which is located in /pkg and depends
on the automounter.

One solution to this problem would be to add After=automount.service
to blinkd.service. This would delay the startup of blinkd to the
point, when automounter has finished startup. However, experiments
showed, that this doesn't work. It looks like the startup
command of automount.service exists after daemon process has been
forked but before the automount paths have been mounted. So
systemd regards automount.service has started before the automount
paths are really available and services with After=automount.service
are still started to early to use them.

That aside, although /usr/bin/python3 is not to go via NFS under
normal circumstances because of the loacl mechanis of mxpkg, under
expectional circumstances this can happen (e.g. when the python3
version is updates). We don't want long-running deamons to lock
nfs mounts, so this would not be a good solution, even if made to
work.

A python3 with the blink1 package from PyPi has been added
to the system [1] and is available as
/usr/local/system/python3/bin/python3.

This python3 installation is guaranteed to be on a local
disk, so use this path in the shebang.

[1] mariux64/pkg-scripts@8e149c1

This is the second part of the blinkd fix (issue #54).

PR #64 prevented the deadlock during service start.

However, currently blinkd is not starting at system boot, because
it uses `env python3` in the shebang. This will activate our default
(big, scientific) python3 which is located in /pkg and depends
on the automounter.

One solution to this problem would be to add After=automount.service
to blinkd.service. This would delay the startup of blinkd to the
point, when automounter has finished startup. However, experiments
showed, that this doesn't work. It looks like the startup
command of automount.service exists after daemon process has been
forked but before the automount paths have been mounted. So
systemd regards automount.service has started before the automount
paths are really available and services with After=automount.service
are still started to early to use them.

That aside, although /usr/bin/python3 does not to go via NFS under
normal circumstances because of the loacl mechanis of mxpkg, under
expectional circumstances this can happen (e.g. when the python3
version is updates). We don't want long-running deamons to lock
nfs mounts, so this would not be a good solution, even if made to
work.

A python3 with the blink1 package from PyPi has been added
to the system [1] and is available as
/usr/local/system/python3/bin/python3.

This python3 installation is guaranteed to be on a local
disk, so use this path in the shebang.

[1] mariux64/pkg-scripts@8e149c1

This is the second part of the blinkd fix (issue #54).

PR #64 prevented the deadlock during service start.

However, currently blinkd is not starting at system boot, because
it uses `env python3` in the shebang. This will activate our default
(big, scientific) python3 which is located in /pkg and depends
on the automounter.

One solution to this problem would be to add After=automount.service
to blinkd.service. This would delay the startup of blinkd to the
point, when automounter has finished startup. However, experiments
showed, that this doesn't work. It looks like the startup
command of automount.service exists after daemon process has been
forked but before the automount paths have been mounted. So
systemd regards automount.service has started before the automount
paths are really available and services with After=automount.service
are still started to early to use them.

That aside, although /usr/bin/python3 does not to go via NFS under
normal circumstances because of the local mechanism of mxpkg, under
expectional circumstances this can happen (e.g. when the python3
version is updates). We don't want long-running deamons to lock
nfs mounts, so this would not be a good solution, even if made to
work.

A python3 with the blink1 package from PyPi has been added
to the system [1] and is available as
/usr/local/system/python3/bin/python3.

This python3 installation is guaranteed to be on a local
disk, so use this path in the shebang.

[1] mariux64/pkg-scripts@8e149c1

This is the second part of the blinkd fix (issue #54).

PR #64 prevented the deadlock during service start.

However, currently blinkd is not starting at system boot, because
it uses `env python3` in the shebang. This will activate our default
(big, scientific) python3 which is located in /pkg and depends
on the automounter.

One solution to this problem would be to add After=automount.service
to blinkd.service. This would delay the startup of blinkd to the
point, when automounter has finished startup. However, experiments
showed, that this doesn't work. It looks like the startup
command of automount.service exists after daemon process has been
forked but before the automount paths have been mounted. So
systemd regards automount.service has started before the automount
paths are really available and services with After=automount.service
are still started to early to use them.

That aside, although /usr/bin/python3 does not to go via NFS under
normal circumstances because of the local mechanism of mxpkg, under
expectional circumstances, this can happen (e.g. when the python3
version is updates). We don't want long-running daemons to lock
nfs mounts, so this would not be a good solution, even if made to
work.

A python3 with the blink1 package from PyPi has been added
to the system [1] and is available as
/usr/local/system/python3/bin/python3.

This python3 installation is guaranteed to be on a local
disk, so use this path in the shebang.

[1] mariux64/pkg-scripts@8e149c1

This is the second part of the blinkd fix (issue #54).

PR #64 prevented the deadlock during service start.

However, currently blinkd is not starting at system boot, because
it uses `env python3` in the shebang. This will activate our default
(big, scientific) python3 which is located in /pkg and depends
on the automounter.

One solution to this problem would be to add After=automount.service
to blinkd.service. This would delay the startup of blinkd to the
point, when automounter has finished startup. However, experiments
showed, that this doesn't work. It looks like the startup
command of automount.service exists after daemon process has been
forked but before the automount paths have been mounted. So
systemd regards automount.service has started before the automount
paths are really available and services with After=automount.service
are still started to early to use them.

That aside, although /usr/bin/python3 does not to go via NFS under
normal circumstances because of the local mechanism of mxpkg, under
exceptional circumstances, this can happen (e.g. when the python3
version is updates). We don't want long-running daemons to lock
nfs mounts, so this would not be a good solution, even if made to
work.

A python3 with the blink1 package from PyPi has been added
to the system [1] and is available as
/usr/local/system/python3/bin/python3.

This python3 installation is guaranteed to be on a local
disk, so use this path in the shebang.

[1] mariux64/pkg-scripts@8e149c1